Data synchronization

ABSTRACT

The invention relates to a method of limiting the size of synchronization messages between a first synchronization device and a second synchronization device. The first device specifies a maximum message size for synchronization messages to be sent to the first device and transmits information on the maximum message size to the second device. The second device transmits to the first device one or more synchronization messages which are equal to or smaller than the maximum message size of the first device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, claims priority to and thebenefit of U.S. application Ser. No. 09/971,213, filed on 3 Oct. 2001,the disclosure of which is incorporated herein by references in itsentirety.

BACKGROUND

The invention relates to data synchronization between two or moresynchronization devices, particularly to limiting the size ofsynchronization messages during a synchronization session. Datasynchronization is an operation in which a correspondence between atleast two data collections is created in such a way that after thesynchronization the units of the data collections substantiallycorrespond to each other.

Data of portable terminals, such as portable computers, PDA (PersonalDigital Assistant) devices, mobile stations or pagers, can besynchronized with network applications, desktop computer applications orother databases in a telecommunications system. Data of calendar ande-mail applications, in particular, are synchronized. Synchronizationhas previously been based on different proprietary protocols which arenot compatible with each other. This restricts the use of terminal ordata types and often causes problems to the user. In mobilecommunication, in particular, it is important to acquire and update datairrespective of the terminal or application used.

The SyncML (Synchronization Markup Language), which is based on the XML(Extensible Markup Language) has been provided for improvedsynchronization of application data. The SyncML synchronization protocolusing messages in the SyncML format (SyncML messages) allowssynchronization of data in any application between any networkedterminals. For example, a calendar entry in a mobile station isautomatically synchronized with the network calendar used by a companysecretary.

FIG. 1 shows an example of synchronization where a mobile station MSfunctions as the SyncML client terminal and a network server S functionsas the SyncML server. The SyncML synchronization service comprises firstinitializing a synchronization session during which e.g. the database tobe synchronized is selected. The SyncML client terminal MSsynchronization application layer functions are provided by asynchronization client agent, which implements the SyncML protocol interalia by sending a SyncML package (Client Modifications), which includes,in one or more SyncML messages, modifications made after the lastsynchronization session to the data that is the object ofsynchronization in the mobile station MS. The SyncML server Ssynchronization application layer functions are provided by a syncserver agent, which controls synchronization, and a synchronizationblock (Sync Engine). The server usually waits for an initiative forsynchronization from the SyncML client (MS). The server S synchronizesthe data, i.e. analyses the changes made to the database and clientterminal data, and harmonizes it (makes necessary modifications,replacements and deletions). After this, the SyncML server S sends theserver modifications back to the SyncML client (MS). The exampledescribed above is simple, yet it illustrates the roles of the devicesaccording to the SyncML standard. The SyncML client terminal (MS) istypically a mobile station (MS), a PC (Personal Computer), a laptop, ora PDA device. The SyncML server S is typically a network server or a PC.

The SyncML synchronization protocol operates in both wireless and wirednetworks and supports several transfer protocols. The SyncMLsynchronization protocol can be implemented, for example, on top of theHTTP protocol (Hyper Text Transfer Protocol), the WSP protocol (WirelessSession Protocol) of the WAP (Wireless Application Protocol) standard,the OBEX protocol used for cable links, such as the USB (UniversalSerial Bus) or RS-232, or for short-range radio frequency (Bluetooth)links or infrared (IrDA) links, on top of a TCP/IP (Transport ControlProtocol/Internet Protocol) stack, and also on top of an e-mail protocol(SMTP, Simple Mail Transfer Protocol). There are typically severaldifferent transmission media between the devices (MS, S) of a SyncMLsession, for instance a GSM network providing a wireless connection, anda local area network LAN. Also many transport layer protocols may beused to transfer SyncML messages. Different transmission media and thedevices involved in the SyncML session may have different properties,e.g. varying data rates and packet sizes. The SyncML consists ofend-to-end transmission of SyncML messages and it has to function eventhough a plurality of transport layer protocols is used. The devices arenot typically aware of the message size they should use when sendingsynchronization messages to each other. If a device sends a large SyncMLmessage, it is possible that the transport layer is not able to deliverit or a receiving device is not able to process it after it has arrived.

BRIEF DESCRIPTION OF THE INVENTION

An object of the invention is to avoid the problem described above andto provide means for limiting the size of transferred synchronizationmessages. The objects of the invention are achieved with a method, asynchronization system, synchronization devices, and computer programproducts which are characterized by what is disclosed in the independentclaims. The preferred embodiments of the invention are disclosed in thedependent claims.

The invention is based on determining maximum message size forsynchronization messages. A first device specifies a maximum messagesize for synchronization messages to be sent to the first device andtransmits information on the maximum message size to a second device.The second device transmits to the first device synchronization messagesthat do not exceed the maximum message size.

The arrangement of the invention has the advantage that the reliabilityof synchronization is improved as the problems caused by too largesynchronization messages are avoided. If there is a large amount ofsynchronization data to be transferred, the data can be divided intomultiple synchronization messages according to the capabilities of thereceiving device.

The term ‘synchronization message’ refers generally to messages composedat the application layer by a synchronization application entity andcomprising synchronization-related data. The synchronization messagesare sent to lower layers (transport layer) for transmission, where theyare changed into transport layer packets. According to a preferredembodiment of the invention, the SyncML protocol is used. Thus theSyncML synchronization message may contain SyncML commands, as well asthe related synchronization data and meta information.

According to a preferred embodiment of the invention, the maximummessages sizes are determined in both devices of a synchronizationsession and the smaller value is chosen as the maximum message size forsynchronization messages in both directions. This embodiment furtherimproves the reliability of the synchronization session.

According to another preferred embodiment of the invention, the firstdevice is a mobile station and the second device is a synchronizationserver. Thus the limited resources, especially temporary memoryresources, of mobile stations can be taken into account already at thesynchronization application level.

According to yet another preferred embodiment of the invention, themaximum message size is determined based on the limitations of atransport layer providing transport of the synchronization messages.This allows the limitations of intermediary devices, such as a WAPgateway, to be considered when determining the maximum message size forsynchronization messages.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in greater detail by means of preferredembodiments with reference to the accompanying drawings, in which

FIG. 1 illustrates synchronization according to the SyncMLsynchronization protocol;

FIG. 2 a illustrates a wireless network and a local area network;

FIG. 2 b illustrates a SyncML client and a SyncML server;

FIG. 3 illustrates a method according to a preferred embodiment of theinvention; and

FIG. 4 is a signaling chart illustrating signaling events according topreferred embodiments of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following, the preferred embodiment of the invention will bedescribed in a system supporting the SyncML standard, without limitingthe invention thereto.

FIG. 2 a illustrates a networked system where data of databases DB andterminals TE can be synchronized. In respect of synchronization theterminal TE functions as a client device. FIG. 2 a shows two examples.In the first one there are terminals TE, databases DB andsynchronization servers S connected to a local area network LAN. Theterminal TE connected to the network LAN comprises a functionality forcommunicating with the devices of the network LAN, e.g. a network cardand software which controls data transmission. The local area networkLAN can be a local area network of any type and the TE can alsocommunicate with the server S via the Internet, typically through afirewall FW. In the second example a terminal TE, a synchronizationserver S and databases DB are connected to a mobile network MNW. Theterminal TE connected to the network MNW comprises a mobile stationfunctionality for communicating wirelessly with the network MNW. Themobile network MNW can be any prior art wireless network, such as anetwork supporting the GSM service, a network supporting also the GPRSservice (General Packet Radio Service), a third-generation mobilecommunication network, such as a UMTS network (Universal MobileTelecommunications System), a wireless local area network WLAN or aprivate network. It should be noted that the server S can also functionas a database DB, even though in FIG. 2 a the servers S and thedatabases DB are shown separately for the sake of clarity. Thus the term‘database’ is to be understood broadly as referring to a data collectionof any data source or data storage that can be updated by one or moreapplications.

As illustrated in FIG. 2 b, the terminals TE (in wired networks LAN andin wireless networks MNW) and the servers S comprise a memory MEM; SMEM,a user interface UI; SUI, I/O means I/O; SI/O for arranging datatransmission and a central processing unit CPU; SCPU, which comprisesone or more processors. The memory MEM; SMEM includes a nonvolatileportion for storing applications controlling the central processor (CPU;SCPU) and a volatile memory portion for data processing. The memory MEMof the TE (which in this example is the database to be synchronized) andthe memory of the databases DB store application data which are to besynchronized. A client agent CA providing the application layerfunctionality according to the invention is preferably implemented byexecuting a computer program code stored in the memory MEM in the CPU.The synchronization server S provides a synchronization agent SA and asynchronization engine SE to provide the synchronization applicationlayer functionality. The TE and the S further comprise protocol entitiesproviding the transport means for SyncML application layer data,especially the transport layer protocol entities TTE and STE utilizingthe I/O means I/O; SI/O. The transport layer generally refers to a layerwhich provides the synchronization application layer with a reliablelogical data transmission connection (not necessarily a protocol of thetransport layer according to the OSI model, such as the TCP). Thecomputer program code, when executed in the central processing unit CPUand the SCPU, causes the terminal TE and the synchronization server S toimplement the inventive means. Embodiments of these means areillustrated in FIGS. 3 and 4. The computer programs can be embedded orobtained via a network and/or stored in memory means, such as a floppydisk, a CD ROM or other external memory means, from which they can beloaded into the memory MEM, SMEM. It is also possible to use hardwaresolutions or a combination of both software and hardware solutions toimplement the inventive means.

FIG. 3 illustrates a method according to a preferred embodiment of theinvention. As a need for determining the maximum message size exists 301in a first SyncML device (either the SyncML client TE or the server S),transport layer-specific and/or SyncML implementation-specificlimitations are determined 302. The need for determining the maximummessage size 301 typically exists as a SyncML session is initiated, butit is possible to determine the maximum message size at any stage of theSyncML session. The term ‘synchronization session’ generally refers tothe end-to-end communication between at least two synchronizationprotocol entities for synchronizing data between at least two devices,without being limited to the SyncML session. The SyncMLimplementation-specific limitations may be limitations affecting thefunctions of the SyncML application entity caused by the chosen hardwareand/or software solutions. Limitations caused by software solutions mayinclude the limitations of the SyncML client agent, server agent or thesynchronization engine. The size of the available memory for the SyncMLapplication entity (CA, SA) is one important factor that can beconsidered. Implementation specific limitations may be caused by theprocessor CPU, SCPU itself. In mobile devices, the processor may be soslow that the SyncML application needs to limit the message size inorder to avoid time-outs, i.e. in order to process received SyncMLmessages and to reply to them quickly enough. In SyncML server devices,the limitations are typically caused by software solutions.

The transport layer-specific limitations refer to transportlayer-specific limitations caused by the implementation of the transportlayer service in the device 1 determining the maximum SyncML messagesize or in some other device (device 2) providing transport layerservices for the SyncML messages. The SyncML application entity (CA, SA)may request transport layer-specific limitations from the transportlayer protocol entity (TTE, STE). The transport layer protocol entity(TTE, STE) may preferably determine the maximum message size that can beused in the transport protocol layer and inform the SyncML applicationentity (CA, SA) about it. Also the transport layer application entity(TTE, STE) specific limitations may limit the maximum message size. Forinstance, the available memory of an HTTP client can be taken intoaccount.

The maximum message size is then determined 303 for SyncML messages onthe basis of the transport layer and/or implementation specificlimitations. If there are both transport layer and implementationspecific limitations for the message size, e.g. a maximum message sizelimit for a transport layer and a workspace memory limitation, thesmallest value is chosen as the maximum message size. Information on themaximum message size is then transmitted 304 to the second SyncML deviceinvolved in a synchronization session with the first device. As thesecond device receives 305 this information, the SyncML applicationentity (CA, SA) is configured to compose and transmit 306 SyncMLmessages which are equal to or smaller than the maximum message size. Ifthe amount of synchronization-related data (SyncML package) to be sentis larger than the maximum message size, the SyncML application entity(CA, SA) may split the data into multiple SyncML messages. If a singledata item, e.g. an email message, is larger than the maximum messagesize, the SyncML application may try to compress it, discard a part ofit or discard the whole data item.

The maximum SyncML message size can be specified for therequest-response pair (SyncML request message—SyncML response message)or for a whole SyncML session. If the device 1 includes the maximumSyncML message size only once, it advantageously means that thereceiving device 2 must follow that size during the whole SyncMLsession. However, the device 1 can include the maximum message size ineach sent message. Then the receiving device 2 must follow the valuespecified in last received message when it sends the next SyncML messageas a response.

It is especially important to determine the maximum size for messagesbeing transferred to mobile stations or other portable devices, as theirprocessing resources are fairly limited. The invention may, however, beimplemented also to limit the message size for other types ofsynchronization devices, such as desktop computers. Device 2 in FIG. 3may also perform the same steps as device 1, and thus the maximummessage size may be informed in both directions. According to anembodiment, the smaller one of the maximum messages sizes is thenselected as the used maximum message size and may be used during thewhole SyncML session. It is also possible to use different values, i.e.one value for SyncML messages transmitted to device 1 and another valuefor messages transmitted to device 2.

In SyncML, the data synchronization operations are conceptually boundinto a SyncML Package. The SyncML Package is just a conceptual frame forone or more SyncML messages that are required to convey a set of datasynchronization semantics. A SyncML message is a well-formed, but notnecessarily valid, XML document. The document is identified by theSyncML root or document element type. This element type acts as a parentcontainer (i.e. a root element type) for the SyncML message. The SyncMLmessage consists of a header, specified by the SyncHdr element type, anda body, specified by the SyncBody element type:

1 <SyncML><SyncHdr> . . . </SyncHdr><SyncBody> . . .</SyncBody></SyncML>

As is well known for the XML language, an element begins with astart-tag (e.g. <section>) and ends with an end-tag (</section>), and itcan contain text or other elements. The SyncML header SyncHdr specifiesrouting and versioning information about the SyncML message. The SyncMLbody is a container for one or more SyncML Commands. The SyncML Commandsare specified by individual element types. The SyncML Commands act ascontainers for other element types that describe the specifics of theSyncML command, including any synchronization data or meta information.

A SyncML DTD (Document Type Definition) defines the XML document typeused to represent a SyncML message. The DTD determines the used tags,structural proportions of the elements (!ELEMENT) between the tags, andother XML document definitions. SyncML messages typically refer to a DTDthat is already known (it is also possible to include DTD in transferredSyncML messages). The maximum message size is preferably determined in aheader part (SyncHdr) of a SyncML message. The content model of theSyncHdr element in the SyncML DTD may be defined as follows:

<!ELEMENT SyncHdr (VerDTD, VerProto, SessionID, MsgID, Target, Source,RespURI?, NoResp?, Cred?, Meta?)>

The question mark ‘?’ denotes that the particular element is optional.‘VerDTD’ specifies the version identifier of the SyncML representationprotocol specification used to represent the SyncML message, ‘VerProto’specifies the version identifier of the SyncML synchronization protocolspecification used with the SyncML message, ‘SessionID’ specifies theidentifier of the SyncML session associated with the SyncML message,‘MsgID’ specifies a SyncML session-unique identifier for the SyncMLmessage, ‘Target’ specifies target routing or mapping information,‘Source’ specifies source routing or mapping information, ‘RespURI?’specifies the URI that the recipient must use for any response to thismessage, ‘NoResp?’ indicates that the originator does not want aresponse status to be sent back in the response message and ‘Cred?’specifies an authentication credential for the originator. The ‘Meta?’element may be used to convey meta information about the SyncMLmessages, it may be used especially to convey information on the maximumbyte size of a SyncML response. Annex 1 illustrates an example of theSyncHdr container element in which the maximum message size isspecified.

The SyncML synchronization protocol can be implemented utilizing varioustransport layer protocols, such as the HTTP protocol, the WSP protocolof the WAP standard, the OBEX protocol used for cable connections, suchas USB or RS-232, for short-range radio frequency connections(Blue-tooth) or for infrared connections (IrDA), the TCP/IP stack or thetransport layer service which is offered by the e-mail protocol (SMTP).Transfer at the lower layers can be performed according to theunderlying network using e.g. short messages or other signaling typetransmission methods (e.g. USSD; Unstructured Supplementary ServiceData), circuit-switched data calls or packet-switched data transferservices.

According to an embodiment, the HTTP protocol is used for providing thetransport layer transmission. In this embodiment the SyncMLimplementation specific limitations are advantageously used to determinethe maximum message size. For instance, the amount or a part of theavailable workspace of the SyncML application is taken as the maximummessage size. It is also possible to consider transport layerlimitations, such as the limitations caused by the HTTP server softwareor the available memory for an HTTP client.

According to another embodiment, the OBEX protocol is used to offer thetransport layer transmission. In this embodiment, the maximum OBEXpacket length is the transport layer specific limitation and may betaken as the maximum SyncML message size. During OBEX linkestablishment, a CONNECT packet is sent between the parties of the OBEXsession (OBEX client and OBEX server) and it indicates the maximum sizeOBEX packet that the device can receive. The OBEX client and server mayhave different maximum lengths. For a more detailed description of theOBEX link establishment, reference is made to Chapters 3.3.1.3 and3.3.1.4 on page 24 of OBEX specification “IrDA Object Exchange Protocol,IrOBEX”, version 1.2, Mar. 18, 1999, Infrared Association. The SyncMLimplementation-specific limitations may also be considered whendetermining the maximum message size.

According to yet another embodiment, the WSP protocol is used to offerthe transport layer transmission. In this embodiment the WSP layermaximum message size determines the transport layer specific limitationto the maximum SyncML message size. The SyncML application entity (CA,SA) requests maximum message size in a WSP session from the WSP entity(TTE and/or STE in FIG. 2 b). The WSP message size may be found outusing a capability negotiation mechanism. The capability negotiation isused for agreeing on WSP session functionality and protocol options. WSPsession capabilities can be negotiated during the WSP sessionestablishment. Capability negotiation allows a WSP server application todetermine whether a WSP client can support certain protocol facilitiesand configurations. For a more detailed description of the WSPcapability negotiation, reference is made to WAP specificationWAP-230-WSP “Wireless Session Protocol Specification”, July 2001,Chapter 6.3.2.1, “Capability Negotiation”, pages 20-22.

It should be noted that more than one transport protocols can be used incommunication between the SyncML client TE and server S and that thusthe server and the client may determine the maximum SyncML message sizedifferently. For instance, an OBEX-link may be used between a mobilestation and a PC and a HTTP-connection may be used between the PC and asynchronization server.

FIG. 4 is a signaling diagram illustrating a preferred embodiment inwhich a WAP stack is used between a TE and a WAP gateway WAP GW, and anHTTP/TCP/IP stack is used between the WAP gateway and thesynchronization server S. When there is a need 401 in the TE tosynchronize data of the databases (e.g. MEM, DB), the SyncML applicationentity (CA in FIG. 2 b) requests the maximum message size from the WSPentity (TTE in FIG. 2 b) and to activate a transport layer connection tothe WAP gateway WAP GW and further to the SyncML server. The connectionis established (a WSP session to the WAP GW and an HTTP connection fromthe WAP GW to the SyncML server S). The WSP capability negotiation isused 402, 403 to determine the maximum message size the WAP gateway isable to handle and, according to a preferred embodiment, this messagesize is also taken 404 as the maximum message size for SyncML messagesto the TE. The TE may also take other limitations into account, such asthe memory limitations or the client message size on the WSP layer, i.e.the maximum message size that can be sent to the client during theSyncML session.

As the transport layer connection is established between the server Sand the TE, the TE transmits 405 a client initialization package to theserver S in one or more SyncML messages (not exceeding the servermaximum message size). The client initialization package informs thesynchronization server S of the maximum message size, the databaseswhose data are to be synchronized, and the type of synchronization to beused. The client initialization package typically also includesauthentication information and information on the services and devicefeatures supported by the terminal TE.

When the terminal TE has specified the maximum SyncML message size, theSyncML server S synchronizing with the terminal may not specify themaximum message size if there are no limitations from its side for thesize of SyncML messages when it receives SyncML messages from theterminal. In this embodiment, the server S also determines 406 themaximum message size for SyncML messages. The server S then sends 407 tothe terminal TE a server initialization package containing typicalinformation on SyncML session initialization and the maximum messagesize determined by the S. The TE selects 408 the maximum message size tobe used during the SyncML session in both directions by selecting thesmaller one of the determined (404, 406) message sizes.

After the initialization has been finished, the data of at least onedatabase DB defined during the initialization and the data of theterminal TE can be synchronized. The type of the synchronization can bee.g.:

Two-way syncOne-way sync from client onlyRefresh sync from client onlyOne-way sync from server onlyRefresh sync from server onlyServer alerted sync.

The SyncML messages transferred 409 during the SyncML session do notexceed the maximum message size. It is possible, however, to change themessage size during the session by including a new maximum message sizein the transferred message. It should be noted that, unlike in FIG. 4,already the server S may compare the maximum message sizes and selectthe used maximum message size.

According to an embodiment, a minimum limit may also be specified forsynchronization messages to ensure efficiency. The limit may be e.g.3000 bytes. Thus, if a maximum message size under 3000 bytes isdetermined or requested, 3000 bytes is selected (408) as the maximummessage size.

It should be noted that the functions illustrated in FIG. 4 can beutilized in synchronization between more than two devices, in which casethe smallest determined maximum message size is preferably used. Unlikein FIG. 4, synchronization can also be started without separateinitialization messages. In that case initialization is performedsimultaneously with synchronization, during which also the informationon the maximum message size may be transferred. In that case the numberof messages to be sent during synchronization can be reduced.

In addition to the description above, the transport layer-specificlimitations may also include lower layer specific limitations, e.g.taking into account the available bandwidth over a wireless connection.The transport layer entity (TTE, STE) may request these limitations fromthe lower layer protocol entities.

It will be obvious to a person skilled in the art that as the technologyadvances, the inventive concept can be implemented in a number of ways.The invention and its embodiments are thus not limited to the examplesdescribed above but may vary within the scope of the claims.

ANNEX 1 <SyncHdr> <VerDTD>1.0</VerDTD> <VerProto>SyncML/1.0</VerProto><SessionID>1</SessionID> <MsgID>1</MsgID><Target><LocURI>http://www.sync-server.com</LocURI> </Target><Source><LocURI>IMEI:123456789012345</LocURI></Source> <Meta> <!--TheMeta is now used to indicate the maximum SyncML message size, which aterminal can receive.--> <MaxMsgSize xmlns =‘syncml:metinf’>5000</MaxMsgSize> </Meta> </SyncHdr>

1. A method, comprising: specifying, in a first device, a maximummessage size for synchronization messages, complying with a syncmlstandard, associated with the first device, transmitting informationrelated to the maximum message size from the first device to a seconddevice, and receiving at the first device one or more synchronizationmessages with a size equal to or smaller than the maximum message sizespecified in the first device, wherein the first device is functioningas a syncml client and the second device is functioning as a syncmlserver, or the first device is functioning as a syncml server and thesecond device is functioning as a syncml client.
 2. A method as claimedin claim 1, further comprising: receiving at the first device a maximummessage size for synchronization messages associated with the seconddevice, and transmitting to the second device synchronization messageswith a size equal to or smaller than the received maximum message sizefor synchronization messages associated with the second device.
 3. Amethod as claimed in claim 1, wherein a maximum message size forsynchronization messages associated with the second device is receivedat the first device, the maximum message sizes for the first device andthe second device are compared, the smaller one of the maximum messagesizes is selected for a synchronization session between the first deviceand the second device, and synchronization messages which are equal toor smaller than the selected message size are exchanged between thefirst device and the second device.
 4. A method as claimed in claim 1,wherein the information related to the maximum message size istransmitted during synchronization session initialization in aninitialization message.
 5. A method as claimed in claim 1, wherein themaximum message size is specified based on implementation specificlimitations of the first device affecting functionality of thesynchronization application entity of the first device.
 6. A method asclaimed in claim 1, wherein the maximum message size is specified basedon limitations of a transport layer providing transport of thesynchronization messages.
 7. A method as claimed in claim 6, wherein thetransport layer is based on a wireless application protocol between thefirst device and a wireless application protocol gateway, and themaximum message size is determined based on the maximum message size thewireless application protocol gateway is capable of transferring.
 8. Anapparatus, comprising: a processor configured to cause apparatus toestablish a synchronization session with a synchronization device,specify a maximum message size for synchronization messages complyingwith a syncml standard associated with said apparatus device, andtransmit information related to the maximum message size to thesynchronization device, wherein, said apparatus is configured tofunction as a synchml client or syncml server
 9. An apparatus as claimedin claim 9, wherein the processor is configured to specify the maximummessage size on the basis of implementation specific limitations of theapparatus affecting the functionality of synchronization applicationentity of the apparatus.
 10. An apparatus as claimed in claim 9, whereinthe processor is configured to specify the maximum message size on thebasis of limitations of a transport layer providing transport of thesynchronization messages.
 11. A synchronization device comprising: meansfor functioning as a syncml client or a syncml server, means forestablishing a synchronization session with another synchronizationdevice, means for receiving information related to a maximum messagesize for synchronization messages, complying with a syncml standard,associated with the other device, and means for transmitting to theother device synchronization messages with size equal to or smaller thanthe maximum message size.
 12. A computer program product, embedded in acomputer readable medium, comprising: computer code configured to causeapparatus to establish a synchronization session between a firstsynchronization device and a second synchronization device, computercode configured to cause apparatus to specify a maximum message size forsynchronization messages complying with a syncml standard, associatedwith said first synchronization device, and computer code configured tocause apparatus to transmit information related to the maximum messagesize to the second synchronization device, wherein the firstsynchronization device is functioning as a syncml client and the secondsynchronization device is functioning as a syncml server, or the firstsynchronization device is functioning as the syncml server and the othersynchronization device is functioning as the syncml client.
 13. Acomputer program product, embedded in a computer readable medium,comprising: computer code configured to cause apparatus to establish asynchronization session between a first synchronization device and asecond synchronization device, computer code configured to causeapparatus to receive information related to a maximum message size forsynchronization messages, complying with a syncml standard, associatedwith the second synchronization device, and computer code configured tocause apparatus to transmit to the second synchronization devicesynchronization messages, complying with syncml standard, with sizeequal to or smaller than the maximum message size, wherein the firstsynchronization device is functioning as a syncml client and the secondsynchronization device is functioning as a syncml server, or the firstsynchronization device is functioning as the syncml server and thesecond synchronization device is functioning as the syncml client.
 14. Asynchronization system comprising a first synchronization device and asecond synchronization device, wherein the first device is configured tospecify a maximum message size for synchronization messages to be sentto the first device and the second device is configured to determine amaximum message size for synchronization messages to be sent to thesecond device, the first device is configured to transmit to the seconddevice information related to the maximum message size forsynchronization messages to be sent the first device, and the seconddevice is configured to compare the maximum message sizes for the firstdevice and the second device, the second device is configured to selectthe smaller size among the maximum message sizes, the second device isconfigured to inform the first device of the selected maximum messagesize, and the first device and the second device are configured totransmit synchronization messages which are equal to or smaller than theselected message size.
 15. A method according to claim 1, wherein theinformation related to the maximum message size is indicated in a metaelement of a synchronization message header.
 16. An apparatus as claimedin claim 9, wherein the processor is configured to transmit theinformation related to the maximum message size, during synchronizationsession initialization, in an initialization message.
 17. An apparatusas claimed in claim 9, wherein the processor is configured to indicatethe information related to the maximum message size in a meta element ofa synchronization message header.
 18. A computer program productaccording to claim 13, the computer program product comprising code fortransmitting the information related to the maximum message size, duringsynchronization session initialization, in an initialization message.19. A computer program product according to claim 13, the computerprogram product comprising code for indicating the information relatedto the maximum message size in a meta element of a synchronizationmessage header.
 20. A computer program product according to claim 14,the computer program product comprising code for receiving theinformation related to the maximum message size, during synchronizationsession initialization, in an initialization message.
 21. A computerprogram product according to claim 14, the computer program productcomprising code for receiving the information related to the maximummessage size in a meta element of a synchronization message header. 22.An apparatus comprising: means for establishing a synchronizationsession with a synchronization device, means for specifying a maximummessage size for synchronization messages, complying with a synchmlstandard, associated with the synchronization device, and means fortransmitting information related to the maximum message size to thesynchronization device, wherein the apparatus is configured to functionas a syncml client or syncml server.
 23. An apparatus, comprising: aprocessor configured to cause apparatus to receive information relatedto a maximum message size for synchronization messages, complying with asyncml standard, associated with a synchronization device, and transmitto the synchronization device synchronization messages, complying withthe synchml standard, with a size equal to or smaller than the maximummessage size, wherein the apparatus is configured to function as asyncml client or a syncml server.
 24. The apparatus as claimed in claim24, wherein the processor is configured to receive the informationrelated to the maximum message size, during synchronization sessioninitialization, in an initialization message.
 25. The apparatus asclaimed in claim 24, wherein the processor is configured to receive theinformation related to the maximum message size in a meta element of asynchronization message header.
 26. A method comprising: receiving, at afirst synchronization device, information related to a maximum messagesize for synchronization messages, complying with a syncml standard,associated with a second synchronization device; and transmitting to thesecond synchronization device synchronization messages, complying withthe synchml standard, with a size equal to or smaller than the maximummessage size, wherein the first synchronization device is functioning asa syncml client and the second synchronization device is functioning asa syncml server, or the first synchronization device is functioning as asyncml server and the second synchronization device is functioning as asyncml client.
 27. The method as claimed in claim 27, wherein theinformation related to the maximum message size is received, duringsynchronization session initialization, in an initialization message.28. The method as claimed in claim 27, wherein the information relatedto the maximum message size is received in a meta element of asynchronization message header.